데이터 중심(Data-Centric) 통신의 패러다임 변화

데이터 중심(Data-Centric) 통신의 패러다임 변화

1. 서론: 복잡성의 위기와 연결의 본질

현대 분산 시스템의 복잡성은 기하급수적으로 증가하고 있다. 국방 시스템의 전장 관리, 자율주행 자동차의 센서 융합, 스마트 그리드의 전력 제어, 그리고 거대 산업 단지의 자동화 시스템에 이르기까지, 소프트웨어는 더 이상 단일 컴퓨터 내에서 완결되지 않는다. 수천, 수만 개의 컴퓨팅 노드가 실시간으로 데이터를 교환해야 하며, 이 과정에서 발생하는 상호 의존성은 시스템의 설계와 유지보수를 극도로 어렵게 만든다. 전통적인 통신 미들웨어는 이러한 복잡성을 해결하기 위해 등장했으나, 여전히 ’메시지를 어떻게 보낼 것인가(How to send)’라는 행위 중심의 사고방식에 머물러 있었다. 이는 시스템의 규모가 커질수록 통합 비용이 폭발적으로 증가하는 ‘N^2의 복잡도’ 문제를 야기했다.1

소프트웨어 공학의 역사에서 연결(Connectivity)은 끊임없는 추상화의 과정이었다. 초기의 소켓(Socket) 프로그래밍은 물리적 연결을 추상화했고, 원격 프로시저 호출(RPC)은 네트워크의 존재를 함수 호출 뒤로 숨겼으며, 메시지 지향 미들웨어(MOM)는 비동기식 전달을 통해 시간적 제약을 완화했다. 그러나 이 모든 진화 과정에서도 변하지 않는 사실이 있었다. 바로 애플리케이션이 데이터의 전송과 흐름을 직접 제어해야 한다는 점이다. 개발자는 데이터를 ‘누구에게’, ‘언제’, ‘어떤 방식으로’ 보낼지를 코드로 작성해야 했으며, 이는 애플리케이션 코드와 통신 코드가 강하게 결합(Tight Coupling)되는 결과를 낳았다.2

데이터 분산 서비스(DDS, Data Distribution Service)는 이러한 문제에 대해 근본적으로 다른 접근 방식을 제시한다. DDS는 통신의 주체를 ’애플리케이션’이나 ’메시지’가 아닌 ’데이터 그 자체’로 정의한다. 이를 ‘데이터 중심(Data-Centric)’ 패러다임이라 부른다. 이 장에서는 데이터 중심 통신이 기존의 메시지 중심 통신과 어떻게 다르며, 이것이 시스템 아키텍처, 개발 프로세스, 그리고 유지보수성에 어떠한 혁명적인 변화를 가져오는지를 심층적으로 분석한다. 데이터 중심성은 단순한 기능의 추가가 아니라, 분산 시스템을 바라보는 세계관의 전환이다.3

2. 메시지 중심(Message-Centric) vs 데이터 중심(Data-Centric)의 철학적 대립

데이터 중심 통신의 본질을 이해하기 위해서는 오랫동안 분산 시스템을 지배해 온 메시지 중심(Message-Centric) 모델과의 명확한 대비가 필요하다. 이 두 모델의 차이는 기술적 구현의 차이를 넘어선 철학적 차이에서 기인한다.

2.1 불투명한 봉투와 투명한 엽서: 데이터 인지 능력

메시지 중심 미들웨어(MOM)에서 데이터는 ’불투명한 봉투(Opaque Envelope)’와 같다.4 애플리케이션 A가 애플리케이션 B에게 메시지를 보낼 때, 미들웨어는 그 봉투 안에 담긴 내용이 온도 센서의 값인지, 비행기의 위치 좌표인지, 아니면 단순한 텍스트 로그인지 알지 못한다. 미들웨어의 역할은 단지 이 봉투를 목적지까지 안전하게 배달하는 운송업자에 국한된다. 따라서 데이터의 내용을 해석하고, 유효성을 검증하며, 데이터 간의 논리적 관계를 처리하는 모든 책임은 애플리케이션 개발자에게 전가된다.2

반면, 데이터 중심 미들웨어인 DDS에서 데이터는 ’투명한 엽서’와 같다. 미들웨어는 교환되는 데이터의 구조(Schema)와 내용(Content)을 명확히 인지한다.3 DDS에서 정보의 단위는 단순한 바이트 스트림이 아니라, ’토픽(Topic)’이라는 이름과 IDL(Interface Definition Language)로 정의된 엄격한 ’타입(Type)’을 가진 데이터 객체다.5 미들웨어가 데이터의 내용을 이해한다는 것은 혁명적인 변화를 가능케 한다. 미들웨어는 데이터의 필드 값을 기반으로 필터링(Content-Based Filtering)을 수행할 수 있고, 데이터의 키(Key)를 통해 개별 인스턴스를 식별할 수 있으며, 데이터의 생명주기를 직접 관리할 수 있다. 즉, 데이터 관리의 복잡성이 애플리케이션 코드에서 인프라스트럭처 레벨로 이관되는 것이다.6

2.2 명령형(Imperative) vs 선언형(Declarative) 통신

메시지 중심 통신은 본질적으로 명령형 프로그래밍(Imperative Programming)의 형태를 띤다. 개발자는 “Send(Message, Destination)” 또는 “Receive(Source)“와 같이 데이터 이동을 지시하는 동사(Verb) 위주의 코드를 작성해야 한다. 이는 시스템의 상태 변화를 애플리케이션이 주도적으로, 그리고 절차적으로 제어해야 함을 의미한다.

데이터 중심 통신은 선언형 프로그래밍(Declarative Programming)에 가깝다. 시스템 설계의 중심은 행위가 아닌 ’데이터 객체(Noun)’다. 개발자는 데이터를 “보낸다“라고 표현하기보다, “이 데이터를 게시(Publish)하겠다” 또는 “이 데이터를 구독(Subscribe)하겠다“라고 선언한다.4 더 정확히 말하면, 게시자는 “나는 이 정보의 최신 상태를 제공할 의무가 있다“라고 선언하고, 구독자는 “나는 이 정보의 최신 상태가 필요하다“라고 선언하는 것이다. 데이터가 실제로 언제, 어떤 경로로, 어떤 빈도로 전달될지는 미들웨어가 데이터에 설정된 품질 정책(QoS) 계약에 따라 자동으로 결정한다.3 이는 개발자가 ’어떻게(How)’가 아닌 ’무엇(What)’에 집중하게 함으로써 시스템의 복잡도를 낮춘다.

2.3 진실의 원천(Source of Truth)의 이동

가장 결정적인 차이는 ’데이터의 상태(State)를 누가 관리하는가’에 있다.

메시지 중심 시스템에서 데이터의 상태는 각 애플리케이션 내부에 캡슐화되어 있다. 애플리케이션 A가 가진 데이터 상태와 애플리케이션 B가 가진 데이터 상태의 동기화는 메시지 교환을 통해 수동으로 이루어진다. 만약 네트워크 지연이나 애플리케이션 충돌로 인해 메시지가 유실되면, A와 B는 서로 다른 ’진실’을 가지게 될 위험이 크다. 시스템 전체의 일관된 상태(Global State)를 유지하기 위해서는 복잡한 동기화 로직과 트랜잭션 관리가 필요하다.7

데이터 중심 시스템에서 DDS 미들웨어는 분산된 로컬 데이터 저장소(Data Local Reconstruction Layer) 역할을 수행한다. 미들웨어 자체가 데이터의 최신 상태를 유지하고 관리하는 주체가 된다. 애플리케이션은 미들웨어라는 거대한 ’분산 데이터베이스’에 접근하여 데이터를 읽고 쓰는 클라이언트와 같은 역할을 한다. 데이터의 일관성, 내구성, 지속성은 미들웨어 인프라 레벨에서 보장된다.6 따라서 애플리케이션이 재시작되거나 네트워크에 늦게 합류하더라도(Late Joiner), 미들웨어로부터 최신 상태의 데이터를 즉시 동기화 받아 시스템의 현재 상태(Current Truth)를 파악할 수 있다.8

특성메시지 중심 (Message-Centric)데이터 중심 (Data-Centric)
통신 단위메시지 (Message)데이터 객체 (Data Object/Topic)
데이터 인지불투명 (Opaque) - 미들웨어는 내용 모름투명 (Transparent) - 미들웨어가 스키마 인지
주요 행위보내기/받기 (Send/Receive)쓰기/읽기 (Write/Read), 게시/구독
초점행위 (Action) 및 전달 (Delivery)데이터 내용 (Content) 및 상태 (State)
상태 관리애플리케이션 책임미들웨어 책임 (Global Data Space)
결합도높음 (Endpoint 의존적)매우 낮음 (Topic 의존적)
데이터 필터링수신 후 애플리케이션에서 처리송신/수신 전 미들웨어에서 처리

3. 글로벌 데이터 공간 (Global Data Space)의 구조와 원리

데이터 중심 통신 패러다임을 실현하는 아키텍처적 핵심은 ’글로벌 데이터 공간(Global Data Space, GDS)’이다.9 GDS는 물리적으로 분산된 네트워크상의 모든 노드들이 마치 하나의 거대한 공유 메모리(Shared Memory)나 중앙 집중식 데이터베이스에 접근하는 것처럼 느끼게 해주는 논리적인 추상화 계층이다.

3.1 가상의 공유 데이터 버스 (Virtual Shared Data Bus)

GDS 개념 하에서 모든 참여자(Domain Participant)는 평등하다. 전통적인 클라이언트-서버 모델의 위계 질서는 사라지고, 오직 정보를 생산하는 자(Publisher)와 소비하는 자(Subscriber)만이 존재한다. 이들은 서로의 물리적 위치(IP 주소, 포트 번호)를 알 필요가 없다.11 단지 자신이 관심 있는 ’토픽(Topic)’의 이름과 데이터 타입만 알면 된다.

애플리케이션이 GDS에 데이터를 쓰면(Write), GDS는 그 데이터를 필요로 하는 모든 구독자에게 자동으로, 실시간으로 배포한다. 이는 하드웨어적인 데이터 버스(Data Bus) 개념을 소프트웨어적으로 확장한 것으로 볼 수 있다. 애플리케이션 개발자 입장에서 GDS는 “데이터를 던져 넣으면(Publish), 필요한 곳에서 튀어나오는(Subscribe)” 마법 상자와 같다. 하지만 내부적으로 GDS는 중앙 서버나 브로커(Broker)에 의존하지 않고, 고도로 최적화된 P2P(Peer-to-Peer) 통신 프로토콜인 RTPS(Real-Time Publish-Subscribe)를 통해 구현된다.12 데이터는 생산자에서 소비자에게로 직접 전달되며, GDS는 이러한 직접 통신을 조율하는 메타데이터와 탐색(Discovery) 정보를 관리하는 분산된 상태 정보의 총합이다. 따라서 중앙 브로커가 병목 지점(Bottleneck)이나 단일 장애 지점(SPoF)이 되는 것을 원천적으로 방지하며, 시스템의 일부가 파괴되더라도 나머지 부분은 정상적으로 동작하는 생존성을 보장한다.3

3.2 데이터 모델링: 토픽(Topic), 키(Key), 인스턴스(Instance)

GDS 내에서 데이터는 관계형 데이터베이스(RDBMS)의 테이블과 매우 유사한 방식으로 관리된다.

  • 토픽(Topic): 데이터베이스의 테이블 이름에 해당한다. 이는 데이터 스트림을 식별하는 고유한 이름이다.
  • 타입(Type): 테이블의 스키마(Schema)에 해당한다. IDL로 정의된 구조체는 데이터의 구조와 필드 타입을 엄격하게 정의한다.
  • 샘플(Sample): 테이블의 행(Row)에 해당하며, 실제 전송되는 데이터 값이다.

DDS의 GDS가 단순한 메시지 버스를 넘어 ’데이터베이스’와 같은 역할을 할 수 있는 핵심 기능은 바로 ’키(Key)’를 통한 인스턴스(Instance) 관리다.5 IDL 정의 시 특정 필드를 키(@key)로 지정하면, GDS는 해당 키 값을 기준으로 데이터 스트림을 논리적으로 분할하여 관리한다.

예를 들어, 항공 관제 시스템에서 AircraftPosition이라는 토픽이 있고, aircraft_id를 키로 설정했다고 가정해보자. 수천 대의 비행기가 데이터를 쏟아내더라도, GDS는 각 aircraft_id 별로 독립적인 인스턴스를 생성하고 관리한다. 미들웨어는 각 비행기(인스턴스) 별로 최신 위치 데이터를 추적하고, 생명주기를 감시한다. 만약 특정 비행기의 통신이 끊기면, 미들웨어는 해당 인스턴스의 상태를 ’NOT_ALIVE’로 변경하여 구독자에게 알릴 수 있다.14 이러한 기능은 개발자가 애플리케이션 코드 내에서 복잡한 해시 맵(Hash Map)이나 리스트를 직접 구현하여 상태를 관리할 필요를 없애준다.

3.3 동적 탐색(Dynamic Discovery)과 플러그 앤 플레이

GDS의 진정한 가치는 시스템의 동적인 변화를 수용하는 능력, 즉 ’동적 탐색(Dynamic Discovery)’에서 드러난다. DDS 미들웨어는 네트워크상에 새로운 참여자(Participant)가 등장하면, SPDP(Simple Participant Discovery Protocol)와 SEDP(Simple Endpoint Discovery Protocol)라는 내부 프로토콜을 통해 자동으로 서로를 인식한다.15

새로운 센서나 제어기가 네트워크에 연결되는 순간, 이 장치는 자신의 존재와 자신이 제공하거나 소비할 데이터(토픽 및 QoS)를 멀티캐스트 등을 통해 GDS에 알린다. 기존 시스템은 별도의 설정 파일 변경이나 재부팅, 관리자의 개입 없이 즉시 새로운 노드를 인지하고, 호환되는 토픽과 QoS를 가진 노드끼리 데이터 파이프라인을 형성한다.11 이는 진정한 의미의 ‘플러그 앤 플레이(Plug-and-Play)’ 시스템 통합을 가능하게 하며, 시스템의 유지보수, 업그레이드, 확장에 드는 비용을 획기적으로 절감시킨다. 클라우드 네이티브 환경이나 동적으로 자원이 할당되는 컨테이너 환경에서도 IP 주소의 변경에 구애받지 않고 통신 연결을 유지할 수 있는 기반이 된다.

4. 분리(Decoupling)의 미학: 시공간과 흐름의 해방

데이터 중심 통신이 제공하는 가장 강력한 아키텍처적 이점은 생산자와 소비자 간의 결합(Coupling)을 극도로 느슨하게 만드는 것이다. DDS는 공간(Space), 시간(Time), 그리고 흐름(Flow)이라는 세 가지 차원에서 완벽한 분리(Decoupling)를 제공한다.16 이는 복잡한 시스템을 유연하고, 확장 가능하며, 진화 가능한 형태로 만드는 핵심 원리다.

4.1 공간적 분리 (Space Decoupling)

공간적 분리는 데이터 생산자와 소비자가 서로의 물리적 위치나 네트워크상의 존재 여부를 알 필요가 없음을 의미한다.19

전통적인 소켓 통신이나 RPC에서는 상대방의 IP 주소와 포트를 정확히 알아야만 통신이 가능하다. 이는 시스템 구성을 정적(Static)으로 만들고, 노드의 이동이나 변경을 어렵게 한다. 그러나 DDS에서는 ’논리적 주소’인 토픽 이름만을 사용하여 통신한다.

  • 위치 투명성(Location Transparency): 게시자는 데이터가 어디로 갈지, 몇 명에게 갈지 고민하지 않고 GDS에 데이터를 게시한다. 구독자는 데이터가 어디서 오는지 신경 쓰지 않고 GDS에서 데이터를 꺼내 쓴다.20
  • N:M 통신의 자유: 1:1 통신뿐만 아니라 1:N(브로드캐스트), N:1(데이터 수집), N:M(협업) 통신을 자연스럽게 지원한다. 데이터가 필요한 곳이라면 어디든(Anywhere) 전달될 수 있다.
  • 이종 시스템 간의 통합: 생산자와 소비자가 서로 다른 프로그래밍 언어(C++, Java, Python, C# 등)나 운영체제(Linux, Windows, RTOS), 하드웨어 아키텍처(x86, ARM)로 구성되어 있어도, GDS는 이들 사이의 데이터 직렬화/역직렬화(Serialization/Deserialization)와 엔디안(Endian) 변환을 투명하게 처리한다.13

4.2 시간적 분리 (Time Decoupling)

시간적 분리는 데이터 생산자와 소비자가 동시에 네트워크에 존재하거나 활성화되어 있을 필요가 없음을 의미한다.18

일반적인 동기식 통신(예: REST API, RPC)에서는 요청을 보낼 때 서버가 켜져 있어야 하고, 즉시 응답해야 한다. 서버가 다운되면 클라이언트는 오류를 겪게 된다. 그러나 DDS는 기본적으로 비동기식(Asynchronous) 통신이며, 여기에 강력한 QoS 정책을 더해 시간의 제약을 뛰어넘는다.

  • 지속성(Durability) QoS: 게시자가 데이터를 보내고 사라지더라도(예: 드론이 착륙하여 전원이 꺼짐), 미들웨어가 그 데이터를 내부 캐시나 지속성 서비스(Persistence Service)에 보관하고 있다가, 나중에 참여한 구독자(Late Joiner)에게 전달할 수 있다.8 이는 시스템 재부팅 시 초기화 과정을 단순화하거나, 통신이 간헐적으로 끊기는 모바일 환경에서 필수적이다.
  • 수명(Lifespan) QoS: 데이터의 유효 기간을 설정하여, 너무 오래되어 가치가 없어진 데이터가 소비자에게 전달되는 것을 방지한다. 예를 들어, 1초 전의 센서 데이터는 유효하지만, 1시간 전의 데이터는 폐기되어야 할 수 있다.23
  • 이력(History) QoS: 구독자가 데이터를 처리하는 속도보다 데이터가 빨리 들어오거나, 구독자가 잠시 연결이 끊겼을 때, 미들웨어가 과거의 데이터 샘플을 얼마나 보관할지(Keep Last N, Keep All)를 결정한다.21

4.3 흐름의 분리 (Flow Decoupling)

흐름의 분리는 생산자와 소비자의 데이터 처리 속도나 네트워크 대역폭의 차이를 미들웨어가 조정해 주는 것을 의미한다.18

고성능 레이더는 초당 수천 번의 데이터를 쏟아내지만, 이를 시각화하는 GUI 애플리케이션은 인간의 인지 능력을 고려하여 초당 수십 번의 업데이트만으로 충분할 수 있다. 또는, 기가비트 이더넷으로 연결된 서버와 저대역폭 무선으로 연결된 핸드헬드 장치가 동일한 데이터를 공유해야 할 수도 있다. 직접적인 연결 방식에서는 생산자가 소비자의 처리 속도에 맞춰 속도를 늦추거나(Blocking), 소비자가 과부하(Overrun)로 인해 데이터를 유실하는 문제가 발생한다.

DDS는 다양한 QoS를 통해 데이터 흐름을 능동적으로 제어한다.

  • 시간 기반 필터(Time Based Filter) QoS: 구독자가 원하는 최소한의 데이터 수신 간격을 설정하여, 미들웨어가 과도한 데이터를 자동으로 솎아내게(Throttling) 한다.4 예를 들어, “나는 최소 100ms 간격으로만 데이터를 받겠다“고 설정하면, 1ms마다 들어오는 데이터 중 99개는 미들웨어 단계에서 걸러지고 1개만 애플리케이션에 전달된다.
  • 콘텐츠 기반 필터(Content Based Filter): 구독자가 특정 조건을 만족하는 데이터(예: “엔진 온도가 100도 이상일 때만”)만 받겠다고 SQL 구문과 유사한 필터를 사용하여 선언하면, 게시자 측에서 데이터를 필터링하여 네트워크로 전송하지 않음으로써 대역폭 낭비를 막는다.24
  • 신뢰성(Reliability) QoS: 모든 데이터를 순서대로 확실하게 받을지(Reliable), 아니면 일부 유실되더라도 최신 데이터를 빠르게 받을지(Best Effort)를 선택하여 통신 흐름의 성격을 정의한다.14

5. 서비스 품질(QoS): 통신의 헌법 (System Constitution)

데이터 중심 패러다임에서 가장 독보적이고 강력한 특징은 바로 세밀하게 조정 가능한 서비스 품질(QoS, Quality of Service) 정책이다.26 메시지 중심 미들웨어에서 QoS가 단순히 ‘배달 보장’ 정도의 옵션이었다면, DDS에서 QoS는 데이터 통신에 대한 ’계약(Contract)’이자 시스템의 비기능적 요구사항(Non-functional Requirements)을 정의하는 ’헌법’과 같다.

5.1 요청(Request)과 제공(Offer) 모델 (RxO)

DDS의 QoS 모델은 엄격한 ‘요청(Requested) vs 제공(Offered)’ 매칭(Matching) 구조를 가진다.14 이는 생산자와 소비자 간의 계약 체결 과정과 유사하다.

  • 제공(Offer): 게시자(Publisher)는 “나는 이 데이터를 매 10ms마다 생성할 것이며(Deadline), 신뢰성 있게 전송할 능력이 있고(Reliability), 최근 10개의 데이터만 저장하겠다(History).“라고 자신의 능력을 선언한다.
  • 요청(Request): 구독자(Subscriber)는 “나는 이 데이터를 최소한 20ms마다 받아야 하며(Deadline), 반드시 신뢰성 있게 받아야 한다(Reliability).“라고 자신의 요구사항을 선언한다.

미들웨어는 탐색(Discovery) 단계에서 이 두 조건을 비교한다. 만약 게시자가 구독자의 요구조건을 충족하지 못하면(예: 게시자는 Best Effort로 보내는데 구독자는 Reliable을 요구하는 경우, 또는 게시자의 Deadline 주기가 구독자의 요구보다 긴 경우), 미들웨어는 연결을 거부하고 애플리케이션에 ‘호환되지 않는 QoS(Incompatible QoS)’ 이벤트를 발생시킨다.14

이러한 RxO 모델은 시스템 설계 단계에서 정의된 데이터 요구사항이 런타임(Runtime)에 엄격하게 준수되도록 강제한다. 개발자가 코드로 예외 처리를 일일이 구현하는 대신, QoS 설정을 통해 “이 데이터 흐름은 반드시 신뢰할 수 있어야 한다“라고 명시하면, 미들웨어가 이를 보장하거나 보장할 수 없음을 즉시 알리는 것이다. 이는 대규모 시스템 통합 시 발생할 수 있는 잠재적인 문제들, 예를 들어 데이터 지연이나 유실로 인한 오동작을 사전에 감지하고 방지하는 강력한 안전장치가 된다.

5.2 데이터 중심의 복잡성 관리 및 코드 절감

QoS는 단순한 설정을 넘어 애플리케이션 로직을 단순화하는 도구다. 실시간성, 신뢰성, 가용성, 보안성 등의 요구사항은 비즈니스 로직과는 별개로 관리되어야 한다. DDS는 이를 미들웨어 레벨로 끌어내림으로써 애플리케이션 코드를 순수한 ’데이터 처리 로직’에만 집중하게 한다.2

예를 들어, 간헐적으로 연결되는 위성 통신 시스템에서 “재연결 시 최근 데이터를 자동으로 동기화하고, 오래된 데이터는 버리며, 대역폭이 부족하면 중요도가 낮은 데이터는 보내지 말라“는 요구사항을 구현한다고 생각해보자. 소켓이나 일반적인 MQ로 이를 구현하려면 수천 줄의 복잡한 상태 관리 코드와 버퍼링 로직, 타이머 처리가 필요하다. 그러나 DDS에서는 DURABILITY=TRANSIENT_LOCAL, LIFESPAN=10sec, TIME_BASED_FILTER 등의 QoS 정책을 XML 설정 파일이나 몇 줄의 코드로 적용하는 것만으로 이 모든 기능이 완벽하게 작동한다.8 코드가 줄어든다는 것은 버그가 줄어든다는 뜻이며, 이는 곧 시스템의 안정성과 생산성 향상, 그리고 검증 비용(Verification Cost) 절감으로 직결된다.

6. 데이터 중심 패러다임의 파급 효과와 미래

데이터 중심 통신의 도입은 단순한 미들웨어 교체를 넘어, 시스템 아키텍처와 개발 방법론 전반에 걸친 혁신을 가져온다.

6.1 시스템 통합(Integration) 비용의 획기적 절감과 상호 운용성

전통적인 시스템 통합은 ’통합 지옥(Integration Hell)’으로 불리곤 했다. 각기 다른 벤더가 만든 하위 시스템(Subsystem)들을 하나로 묶을 때, 인터페이스 불일치, 데이터 포맷의 차이, 통신 타이밍 문제 등이 발생하기 때문이다.

DDS 기반 시스템에서는 사전에 정의된 데이터 모델(IDL)과 QoS 정책이 곧 명확한 인터페이스 명세서가 된다. 각 팀은 GDS라는 공통의 버스에 맞춰 개발하기만 하면 된다. 실제로 미 해군의 함정 전투 시스템이나 거대한 산업용 로봇 시스템과 같은 대규모 복합 체계(System of Systems)에서 DDS 도입 후 통합 비용과 기간이 획기적으로 단축된 사례가 다수 보고되고 있다.6 데이터 중심 접근은 모듈 간의 의존성을 최소화하여 ’느슨한 결합(Loose Coupling)’을 실현하기 때문이다. 또한, OMG 표준을 준수하는 서로 다른 벤더(RTI, eProsima, ADLINK 등)의 DDS 구현체끼리도 상호 운용성(Interoperability)이 보장되므로, 특정 벤더에 종속(Lock-in)되는 것을 막을 수 있다.13

6.2 확장성(Scalability)과 엣지 컴퓨팅(Edge Computing) 최적화

중앙 브로커가 없는 P2P 구조와 데이터 중심의 필터링 기능은 DDS를 엣지 컴퓨팅과 IIoT(Industrial IoT) 환경에 최적화된 솔루션으로 만든다.28 수천 개의 엣지 디바이스가 중앙 클라우드를 거치지 않고 로컬에서 직접 데이터를 주고받으며 마이크로초(µs) 단위의 초저지연(Ultra-Low Latency) 제어를 수행할 수 있다.3 동시에 필요한 데이터만 선별하여 클라우드로 전송하거나, 여러 단계의 게이트웨이를 거쳐 데이터를 집계(Aggregation)하는 계층적 아키텍처를 쉽게 구성할 수 있다. 데이터 중심 패러다임은 데이터가 생성되는 위치에서 소비되는 위치까지의 경로를 논리적으로나 물리적으로 최단거리로 단축시킨다.

6.3 인공지능(AI) 및 자율 시스템과의 융합

자율주행차나 로봇과 같은 자율 시스템은 ’인지(Perception) - 판단(Planning) - 제어(Control)’의 루프를 극도로 빠르게 반복해야 한다. 이때 각 단계 사이를 흐르는 것은 라이다(LiDAR), 카메라, 레이더 등에서 쏟아지는 방대한 양의 데이터다. 데이터 중심 통신은 이러한 대용량 데이터 스트림을 실시간으로 처리하고 공유하는 데 이상적인 백본(Backbone)을 제공한다.30 특히 AI 모델이 시스템에 추가될 때, 기존 제어 시스템의 코드를 수정하지 않고도 GDS 상에서 흐르는 데이터를 ’도청(Snoop)’하여 학습하거나, 추론 결과를 새로운 토픽으로 게시하여 시스템에 피드백을 줄 수 있다. 이러한 유연성은 AI 기술의 빠른 발전 속도를 시스템에 즉각적으로 반영할 수 있게 한다.

6.4 결론: 미들웨어의 주권 회복

요약하자면, 데이터 중심 통신(Data-Centric Communication)은 **“데이터를 올바른 시간(Time), 올바른 장소(Space)에, 올바른 품질(QoS)로 전달하는 것”**을 애플리케이션 개발자의 숙제에서 미들웨어의 주권(Sovereignty)으로 가져오는 패러다임 전환이다. 이는 개발자에게 통신의 ’배관 공사(Plumbing)’에서 벗어나 데이터의 ’가치 창출’과 ’알고리즘’에 집중할 수 있는 자유를 부여한다. DDS는 단순한 통신 프로토콜 라이브러리가 아니라, 분산 시스템을 데이터 중심으로 재편하고, 복잡성을 제어하며, 시스템의 진화를 가능케 하는 핵심 아키텍처 프레임워크인 것이다.

이러한 패러다임의 변화를 명확히 이해하는 것은 이어지는 장들에서 다룰 DDS의 구체적인 기능들—IDL 정의, 토픽 설계 전략, QoS 튜닝 기법, 보안 설정—을 올바르게 활용하기 위한 필수적인 전제 조건이다. 이제 우리는 이 거대한 ’글로벌 데이터 공간’을 어떻게 실제로 설계하고 구축해 나갈지 상세히 알아볼 것이다. 1

7. 참고 자료

  1. Data-Centric Middleware - RTI, https://www.rti.com/hubfs/docs/RTI_Data_Centric_Middleware.pdf
  2. Message Protocols: Data-Centric vs. Data-Centric - EEJournal, https://www.eejournal.com/2015/04/20/message-protocols-data-centric-vs-data-centric/
  3. PROVEN DATA CONNECTIVITY STANDARD FOR THE IOT™, https://www.omg.org/intro/DDS.pdf
  4. Message-Centric Vs. Data-Centric | Bulldozer00’s Blog, https://bulldozer00.blog/2012/08/13/message-centric-vs-data-centric/
  5. 3.5.1. Topics, keys and instances - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/2.x/fastdds/dds_layer/topic/instances.html
  6. What is DDS? - DDS Foundation, https://www.dds-foundation.org/what-is-dds-3/
  7. Why data-centric is bad? - Stack Overflow, https://stackoverflow.com/questions/15321016/why-data-centric-is-bad
  8. DURABILITY QoS Parameter - DDS Foundation, https://www.omgwiki.org/ddsf/doku.php?id=ddsf:public:guidebook:06_append:02_quality_of_service:durability
  9. Data Distribution Service (DDS) - Object Management Group (OMG), https://www.omg.org/omg-dds-portal/
  10. What Is DDS? - MATLAB & Simulink - MathWorks, https://www.mathworks.com/help/dds/gs/dds-conceptual-overview.html
  11. The Data Distribution Service, https://www.cs.wm.edu/~dcschmidt/PDF/dds-sos.pdf
  12. Data-Centric Programming Best Practices: - RTI, https://www.rti.com/hubfs/docs/DDS_Best_Practices_WP.pdf
  13. The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification - Object Management Group (OMG), https://www.omg.org/spec/DDSI-RTPS/2.2/PDF
  14. Advanced Tutorial Using QoS to Solve Real-World Problems - DDS Foundation, https://www.dds-foundation.org/sites/default/files/DDS_Advanced_Ttutorial_00-T5_Hunt-revised.pdf
  15. The DDS Global Data Space. | Download Scientific Diagram - ResearchGate, https://www.researchgate.net/figure/The-DDS-Global-Data-Space_fig7_221926739
  16. Dynamical decoupling - Wikipedia, https://en.wikipedia.org/wiki/Dynamical_decoupling
  17. Decoupling Architecture, https://www.itarch.info/2020/05/decoupling-architecture.html
  18. (PDF) Adaptive real-time video transmission over DDS - ResearchGate, https://www.researchgate.net/publication/224167650_Adaptive_real-time_video_transmission_over_DDS
  19. The Road to Reactive: Understanding the Temporal and Spatial Decoupling - Medium, https://medium.com/event-driven-utopia/the-road-to-reactive-understanding-the-temporal-and-spatial-decoupling-1fd49f52229a
  20. Data Distribution Service - Wikipedia, https://en.wikipedia.org/wiki/Data_Distribution_Service
  21. Data Distribution Service: An Overview Part 1 | Trend Micro, https://www.trendmicro.com/en/research/22/g/data-distribution-service-part-1.html
    1. Quality of Service — The Data Distribution Service Tutorial, https://download.zettascale.online/www/docs/Vortex/html/ospl/DDSTutorial/qos.html
  23. RTI® Connext® DDS—Comprehensive Summary of QoS Policies, https://community.rti.com/static/documentation/connext-dds/5.3.1/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_QoS_Reference_Guide.pdf
  24. DDS – The Proven Data Connectivity Standard for IoT TM - Twin Oaks Computing, Inc, https://www.twinoakscomputing.com/datasheets/DDS-Brochure.pdf
  25. Content-Subscription Profile - OpenDDS 3.34.0-dev, https://opendds.readthedocs.io/en/master/devguide/content_subscription_profile.html
  26. DDS Standard - Data Distribution Service for Complex Systems - RTI, https://www.rti.com/products/dds-standard
  27. Modeling the QoS parameters of DDS for event-driven real-time applications | Request PDF, https://www.researchgate.net/publication/274072933_Modeling_the_QoS_parameters_of_DDS_for_event-driven_real-time_applications
  28. Why Choose DDS? - DDS Foundation, https://www.dds-foundation.org/why-choose-dds/
  29. Navigating IIoT Protocols: Comparing DDS and MQTT - RTI, https://www.rti.com/blog/comparing-dds-and-mqtt
  30. MQTT Broker Architectural Enhancements for High-Performance P2P Messaging: TBMQ Scalability and Reliability in Distributed IoT Systems - MDPI, https://www.mdpi.com/2624-831X/6/3/34